The present invention pertains generally to the field of computer networking. More particularly, the present invention pertains to software applications used for configuring networking hardware installed on a computer system.
Computer networks can be arranged in numerous configurations and in a variety of network types. Some of the most popular types of networks are Ethernet (coaxial cable or twisted-pair cable), token ring, Fiber Distributed Data Interface (FDDI), Frame Relay, Integrated Services Digital Network (ISDN), X.25, and Synchronous Data Link Control (SDLC). Typically, these networks are arranged in local area networks (LANs) and wide area networks (WANs). Usually, LANs are distinguished from WANs based upon the geographical area they cover and sometimes the number of users connected to the network. For example, a group of personal computers (PC) in a home or single business site (location) usually communicate with each over a LAN. Groups of PCs that are at remote locations from one another, such as those in different homes, different companies, or different branch offices of the same company, typically communicate with each other over a WAN. Most WANs typically require significant resources to provide service to a large number of users spread over a vast geographical area causing a WAN to be relatively expensive to build and maintain.
Some users utilize the Internet for virtual private networking to avoid the costs of a true private WAN network and/or paying for long distance communication bills. In essence, virtual private networking entails encrypting and decrypting IP packets for transport across the Internet. In some virtual private networks (VPNs), the payload portion of an IP packet is encrypted for transport across the Internet. The header information is left intact so that routers can forward the packet as it traverses the Internet. In other VPNs, an entire IP packet is encrypted and then encapsulated into new IP packets for transport across the Internet.
One use of the VPN is that it allows a mobile computer system (e.g., a laptop) to be connected to a remote LAN. Typically, a user of the mobile computer system initiates a local call to an Internet Service Provider (ISP) and establishes an Internet session. Then, the mobile computer system sends an Internet message via the Internet to the remote LAN. The mobile system and the remote LAN then engage in a security protocol or handshaking to verify the user is an authorized user permitted to have access to the LAN. Once it is established the user is authorized to have access to the second LAN, a VPN is established, allowing the user and the remote computer system to access data stored within the LAN.
Windows 95(copyright) and Windows 98(copyright) operating systems, however, do not provide native support for several types of VPNs. Therefore, a VPN software package is typically required to be installed in a system to provide for such specialized networking needs. xe2x80x9cVirtualxe2x80x9d network interface cards (NICs) are often installed as part of a VPN software package. By way of background, xe2x80x9crealxe2x80x9d NICs are those associated with one or more pieces of hardware installed on the computer. They include PCI NIC cards, ISA NIC cards, PCMCIA NIC cards, USB NIC cards, etc. A xe2x80x9cvirtualxe2x80x9d NIC is one that is not associated with any hardware. Some examples of xe2x80x9cvirtualxe2x80x9d NICs include xe2x80x9cDial-Up Networking,xe2x80x9d xe2x80x9cInternet Connection Sharing,xe2x80x9d and xe2x80x9cVPN.xe2x80x9d Virtual NICs are well known in the art and are a common way of providing specialized networking support.
When a VPN client is installed under Windows 95(copyright) or Windows 98(copyright), it redirects a NIC""s TCP/IP bindings, sometimes using one or more software virtual NICs. This redirection is done in the Windows(trademark) System registry. Since the various VPN clients use slightly different methods for redirecting the TCP/IP bindings, it becomes difficult for a software application to reliably detect the TCP/IP binding for a particular NIC. To make matters worse, when a VPN is installed, the standard detection scheme for determining where the TCP/IP settings for each NIC are located in the registry no longer works.
Therefore, what is needed is a software application that allows an administrator or end-user to more easily modify the network settings associated with the Network Interface Cards (NICs) installed on a computer, whether or not a VPN client is installed.
Accordingly, the present invention provides a method for detecting TCP/IP (Transmission Control Protocol/Internet Protocol) bindings for Network Interface Cards (NICs) installed on Windows 95(copyright) and Windows 98(copyright) operating systems with a VPN (Virtual Private Network) client present. More particularly, the present invention provides a method for parsing the Windows(trademark) system registry to detect TCP/IP bindings for network interface cards installed within a host computer system. One embodiment of the present invention provides a DriverCheck function and a HardwareCheck function that can be implemented as parts of a computer software that detects TCP/IP bindings for installed network interface cards.
In accordance with one embodiment of the present invention, in order to determine whether a NIC (Network Interface Card) is bound to TCP/IP, the xe2x80x9cNetxe2x80x9d registry key for the NIC must be known. This is the key representing the NIC that is located under the xe2x80x9cHKEY_LOCAL_MACHINE System CurrentControlSet Services Class Netxe2x80x9d registry key. Using the key as an input, the DriverCheck function and the HardwareCheck function of the present embodiment will return TRUE if the NIC is bound to TCP/IP, and FALSE otherwise. If TRUE is returned, the DriverCheck function of the present embodiment will also return the registry key location for the TCP/IP binding for that NIC.
In one embodiment, the DriverCheck function receives a value representing a registry key under the tree xe2x80x9cHKEY_LOCAL_MACHINE System CurrentControlSet Services Classxe2x80x9d, and opens an xe2x80x9cNdixe2x80x9d subkey of the registry key. DriverCheck then extracts a xe2x80x9cDeviceIDxe2x80x9d string value from the xe2x80x9cNdixe2x80x9d subkey. Thereafter, DriverCheck searches all the registry keys under the xe2x80x9cHKEY_LOCAL_MACHINE Enumxe2x80x9d key for a hardware key that matches the xe2x80x9cDeviceIDxe2x80x9d string value. If it is found, DriverCheck calls a HardwareCheck function with the first hardware key as input. HardwareCheck may return the TCP/IP registry key location. If so, the DriverCheck process could terminate.
If HardwareCheck does not return the TCP/IP registry key location, DriverCheck extracts a xe2x80x9cMacNamexe2x80x9d string value from the registry key, and searches all the registry keys under the xe2x80x9cHKEY_LOCAL_MACHINE Enumxe2x80x9d key for a second hardware key that matches the xe2x80x9cMacNamexe2x80x9d string value. If a matching hardware key exists, DriverCheck calls HardwareCheck with the second hardware key as input. Again, if HardwareCheck returns the TCP/IP registry key location, the DriverCheck process could terminate.
If HardwareCheck still fails to return the TCP/IP registry key location, DriverCheck opens a xe2x80x9cNdi Compatabilityxe2x80x9d subkey of the registry key, and extracts an item from a xe2x80x9cRequireAllxe2x80x9d string value found therein. DriverCheck then searches all the registry keys under the xe2x80x9cHKEY_LOCAL_MACHINE Enumxe2x80x9d key for a third hardware key that matches the item; and calls the HardwareCheck with the third hardware key as input if such a matching key can be found. If HardwareCheck returns the TCP/IP registry key location, the DriverCheck process could terminate.
In furtherance of one embodiment of the present invention, the HardwareCheck function receives a hardware key and opens a xe2x80x9cBindingsxe2x80x9d subkey under the hardware key. HardwareCheck enumerates every string value name under the xe2x80x9cBindingsxe2x80x9d subkey. For every string value name enumerated, HardwareCheck creates a first variable BindingName representative of the string value name and a second variable BindingPath representative of a concatenation of a string xe2x80x9cHKEY_LOCAL_MACHINE Enum Network xe2x80x9d and BindingName. HardwareCheck then determines if BindingName begins with xe2x80x9cMSTCPxe2x80x9d. If so, HardwareCheck returns the variable BindingPath as TCP/IP registry key location for the network interface card.
If the BindingName does not begin with xe2x80x9cMSTCPxe2x80x9d, HardwareCheck opens a second registry key with the name as represented by BindingPath, and extracts a xe2x80x9cDriverxe2x80x9d string value therefrom. HardwareCheck then determines whether the xe2x80x9cDriverxe2x80x9d string value starts with xe2x80x9cNetClientxe2x80x9d or xe2x80x9cNetServicexe2x80x9d. If so, HardwareCheck then selects another string value name under the xe2x80x9cBindingsxe2x80x9d subkey for further processing.
If the xe2x80x9cDriverxe2x80x9d string value does not start with xe2x80x9cNetClientxe2x80x9d or xe2x80x9cNetServicexe2x80x9d, HardwareCheck then calls itself recursively using the registry key referred to by BindingPath as input. The recursively called HardwareCheck may return the TCP/IP registry key location.
If the recursively called HardwareCheck does not return the TCP/IP registry key location, HardwareCheck then generates a new driver string by appending the xe2x80x9cDriverxe2x80x9d string value to xe2x80x9cHKEY_LOCAL_MACHINE System CurrentControlSet Services Class xe2x80x9d. HardwareCheck then calls DriverCheck using the registry key referred to by the new string as input. DriverCheck may then return the TCP/IP registry key location. Otherwise, HardwareCheck should exit, indicating that the TCP/IP registry location could not be found.